The present embodiments relate to simulation. For example, a tool for designing and/or performing a simulation of movement of a model is provided.
A three-dimensional simulation environment may be provided within a CAD tool or other software for simulation of the behavior of a geometric model. Such engineering tools may allow re-use of existing models from libraries. Primitive elements form the basis of the tool. A primitive element is code that may represent an object. Elements may be assembled to make a new, more complex, item. The assembly of elements may be called a part. The part is a file that may be stored as an individual selectable entity for use in the tool. The part may represent an actual part, such as a motor. The part file provides a reference to the part contents of the assembly. For example, if the parts are stored as files, the user may load the part file as the main file to be edited, make changes, and store the modifications. When loading an assembly that references that modified part, the assembly incorporates the changes. Assemblies of parts may also be created as part files and may be included by reference in the file into other assemblies.
A full CAD or simulation model may be realized as a hierarchy of parts represented in part files. The graph of parts is restricted to being acyclic in order to avoid endless loops or failure of the simulation. This means that a part file cannot include a reference to itself either directly or through a chain of other referenced part files. Similarly, a part file cannot reference a part file that already references itself. As a result, there is a well defined owner-child relationship between connected part files. Though cycles are prevented, an assembly may still include a part multiple times either directly or by including other parts that also include a common part. However, the owner-child relationship between referenced part files causes some restrictions on how items represented within the part files may interact. In general, an item in a part file may reference objects in part files that are included and their sub-parts. This makes sense in that part files are included in the first place so that their items may be used. However, going the other way where a part file refers to items defined in its owner or part file above is not workable. A part file that gets included in another does not know a priori which part files to which the part file will become attached. Presumably, a part file may be included in many different assemblies so the items in the owner cannot be known.